Standards Metadata Element Set, v3.0
Comments Submitted During Public Review

Compiled February 2003

Comments organized by metadata element:  

a.        General comments
b.        Designation
c.        Title  (no comments)
d.        Description
e.        Identifier
f.         Name of Standards Developing Organization (SDO)
g.        SDO Committee
h.        SDO Information
i.         Subject
j.         Current Status
k.        Date of Most Recent Action
l.         Referenced Standards
m.        Replaces
n.        Related Resources
o.        Format
p.        Language
q.        Rights Management  

Participants  
Appendix  

a.       General comments  

1.    Issue of several fields being optional – why?  If the purpose is so SDO’s can exchange information and define data that is stored, (“What the Standards Registry committee members seek is to develop is a common description or format for storing this data…”), the exchange should be a complete description of the standards.  If one wanted to take a minimalist view, any standard could then be adequately described with the following fields:        

•    Name  

•    Document Title

•    Name of Standards Developing Organization

•    Current status

      This conveys less information than most bibliographical references!  Especially essential are things like “SDO committee”, “format”, etc.   Here is an opportunity to answer all/most questions about a standard, at once.  (are we going to make a phone call/email to get the rest of the info if it doesn’t appear in the database entry?)  If the issue is display of certain fields in a browsed listing of standards, then this is a different issue (a quick list of certain subject standards would not want to list all attributes, so some would be optional).  Opinion: for a database entry, most fields are required. If display of info about a standard is a separate issue, have a field called something like “required for minimal display”.  (American Welding Society A9 Committee)           

2.    Too few [elements]:  We suggest the addition of the element “version number” with its description.  (The version number is controlled by the SDO or by the author of the standard being entered into the catalog.  The version number is important for any standard subject to revision.)  Note that the Dublin Core v1.1 attributes include “version.”  (ITS)  

3.    Too many [elements]:  We, the developers of the JSR, do not plan to include the element “language” in our list of elements identifying a standard in the JSR; all of our standards/specifications will be in English.  (ITS)  

4.    Our experience tells us that precise data for some of the data elements may be very elusive and difficult to identify.  (ITS)  

5.    In our experience, agreement on specific keywords is difficult to achieve. (We agree that keywords are important and must be controlled.) (ITS)  

6.     Accurate data entry on a volunteer basis may be difficult to obtain and validate in a timely manner.  (ITS)  

7.     You may wish to provide more examples and more detailed help files as hyperlinks.  (ITS)  

8.    Our experience has convinced us that most custodians of standards repositories will have serious concerns about security and data integrity, neither of which is addressed in this specification.  Perhaps these exclusions are deliberate because of the system-specific configuration of each repository.  (ITS)  

9.    In our experience, the custodians of the repository have found it useful to provide hyperlinked help files (text) connected with each data element to be entered into the repository.  The subject specification does not include or discuss hyperlinked help files, perhaps because such files would need to be tailored specifically to each individual repository’s design and web function.  (ITS)  

10.    We think consideration should be given to making the description, the subject and the date of most recent action mandatory. (Stephen P. Oksala)  

11.  How likely is it that [our] organization would use this specification?   Very likely. However, we will not likely need the element of “language,” since all of our specifications in the JSR will be  in English.  We have already used this specification to good advantage.  It has proved to be a useful check of the thoroughness of the standards bibliographic data that we have entered into our Justice Standards Registry for Information Sharing (JSR), now online at http://www.it.ojp.gov/jsr/public/index.jsp  (ITS)  

12.  There is a space dedicated to Published Subjects defined by OASIS Technical Committees at http://psi.oasis-open.org/   Whatever the scheme adopted for specification identifiers, this scheme could be included in an URL scheme under the previous space, e.g. for the proposed examples, something like:

http://psi.oasis-open.org/spec/wp-ubl-codelist-01/, http://psi.oasis-open.org/spec/cs-sstc-core-00/    This is of interest for both Published Subjects and Standards Registry application. This is an opportunity for Topic Maps Published Subjects Technical Committee to "eat its own dog food", by defining OASIS specifications as Published Subjects. For those who are not aware of what Published Subjects are  about, please refer to www.oasis-open.org/committees/tm-pubsubj/   (ITS)  

13. It would be interesting to use for those PSI the metadata defined by the Standards Registry effort. http://www.ansi.org/reports/master.asp?room=70  Of course, definition of Published Subjects, use of StdsReg metadata, definition of identifiers scheme, and definition of templates for specification documents, are to be considered as orthogonal issues, but we have there indeed a great opportunity of coordination.  (Bernard Vatant)  

14.  Here’s two standards there have been two separate editions published in the same year, demonstrating what I said at the meeting yesterday that an extra data element is required to be able to identify uniquely an ISO or ISO/IEC standard. The existence of more than one edition in the same year is rare, and I realize in some ways its a shame to have to add to the elements to accommodate such a rare event since one of your goals is to have a limited number of elements. Meanwhile as far as I am aware there is no rule disallowing this and so one cannot exclude that other cases may exist at some point in the future. It wouldn't surprise me if different standards bodies had different names to represent such "versioning" of documents (edition, version, etc.), and in fact within ISO we have been thinking of how we can identify better our documents. Accordingly I wouldn't propose that the element be named "edition"; maybe "Version" would be more appropriate and edition be mentioned in the definition column.  

      Example 1:          ISO 8378-3:1986 1^st edition      ISO 8378-3:1986 2^nd edition
            Example 2:          ISO 11076:2000 2^nd edition      ISO 11076:2000 3rd edition

… demonstrating that you also need the edition to distinguish between the two. Or, of course, as an alternative, you could use the publication date, but not all organizations use a publication date do they?   (Joanna Goodwin)

15.  The Dublin Core v1.1 is indeed an ANSI standard (ANSI/NISO Z39.85-2001) and soon to be an ISO standard, ISO DIS 15836, out of ISO TC 46/SC 4. These references should be made explicit in a document about standards metadata.   (Dan Gillman)

16.  I don’t see something like “sanctioning organization of SDO”, e.g. what ANSI is to AWS.   This is potentially useful/essential info.  (American Welding Society A9 Committee)  

17.  Suggest generate and publish some examples, especially of well known standards from different organizations and in different areas.   Examples would educate new users and help validate the scheme.   Two encodings of AWS documents are included below.  (American Welding Society A9 Committee)  

18.  “What indication is made if an organization will not furnish any drafts of documents until they go out for public approval?”  (Lionel Difford)  

19.  The third and last question was, “By whom would this standard be updated?”   (Lionel Difford)

20.  There are often cases where an existing standard or technical report is very similar to, but not identital to, a new document. There is often reluctance to obsolete products by removing the specific standard to which products were designed. Yet there is a need to provide timely information in the form of new documents. I suggest that an element be added that cites previous documents that address the same subject as the new document with specific information that indicates whether the new document is in addition to or is intended to replace the older document(s). This is different from listing the normative references in that this new element identifies previous documents with similar scopes to the new document. The element proposed in the current metadata spreadsheet that specifies which existing documents are replaced by the new document accomplishes part of the goal of the comment. However, the larger risk is that the new document does not replace the older one, that both exist in force, that conflicting requirements are stated between the two documents, and that confusion is likely.   (Bill Ham)  

21.  The technical editor(s) of the documents should be identified as separate element as these are the people who are best qualified to provide supplemental information on the technical content of the documents.   (Bill Ham)  

22. If the decision is made to keep this set of metadata a simple, flat list of elements (ala Dublin Core), then there are some complications that will have to be handled somewhat awkwardly. I submit that this simplification will ultimately limit services (access, display, links to authoritative schemes, etc.) and database design. The following recommendations are made with the assumption that a somewhat more complex metadata design would be acceptable in order to make the collected data more useful. I would also recommend that the standard be expressed as an XML schema where attributes of elements is a useful device for representing some types of description.   (Linda Hill)  

23. In general, the specification lacks precision. There are many ways this is evident, for instance, all but one of the attributes has a datatype of “character string.”  Use of a formal datatyping language, such as in ISO/IEC 11404 (Language Independent Datatypes), is needed. Other formal data typing specifications exist, too.   (Andy Schoka)  

24.  Typical kinds of standards wording are not in evidence. Terms are not defined. Definitions are not precise. References are missing or not adequate.   (Dan Gillman and Frank Farence)  

25. No attributes for handling registration exist in the specification.   (Dan Gillman and Frank Farance)  

26.  The Obligation/MaxOccurence fields are imprecise. For instance, the attribute “Referenced Standards” is optional and unlimited. Does this mean you can specify a standard more than once? Does the list have to be in some kind of order? Does there need to be an index (e.g. numbering) to the list?   (Dan Gillman and Frank Farance)  

27. There is no provision for multilingual representations. Many ISO standards are published in both French and English.   (Dan Gillman)  

28. Attributes for “Introduction”, “Scope”, and “Terms and Definitions”, sections commonly seen in standards documents, need to be added.   (Dan Gillman)  

29. Definitions of attributes are not precise. For instance, what does “unambiguous” really mean?   (Dan Gillman and Frank Farance)  

30. The work needs to be harminized with work in ISO TC 46. Has this been done?   (Dan Gillman)  

31.  The specification references the Dublin Core v1.1.  Why?  Several attributes map to Dublin Core elements. Why choose different names?  Several attributes map to the SAME Dublin Core elment (e.g. SM attributes “Designation” and “Identifier” both map to DC element “Identifier”, both map to DC element “Identifier”, and SM attributes “Name of Standards Developing Organization (SDO)” and “SDO Committee” both map to DC element “Creator or Publishor”). This indicates that maybe the Dublin Core is not extensive enough. So why is there mapping at all?   (Dan Gillman)  

32.  Do you handle archival records and if so, how do you treat them?: “Withdrawn” status? “Is Replaced By” element?  (Standards Metadata Registry Committee)

b.        Designation  

1.     Why is “Designation” optional?  Is there any circumstance where one would not exist?  If it exists, why would you not store it?  (American Welding Society A9 Committee)  

2.     While it would appear that having a designation, a title, and an identifier should be more than sufficient, it might not be so.  We have standards which have one designation while they are under development, and a different designation after approval.  For example - SCTE 55-1 2002 was known for its development life as DVS 178.  In addition, we have standards which have also been approved by ITU.  An example of this is SCTE 24-14 2002.  It was known during development as DSS 02-11, and it has been adopted as ITU Recommendation J.173.  All three of these designations might show up in a reference list (depending on when the reference was created), and two of them will continue.  So it may be necessary to have some kind of "alias" list.  There seems to be an assumption here that the international version of a standard is a separate creature from the national document from which it was taken, and no consideration of a bidirectional link. (Stephen P. Oksala)  

3.     The definition of the “Designation” element should read: “An unambiguous…” instead of “A unambiguous….”  (ITS)

4.     The comment in the “Designation” attribute description shows that the MaxOccurence is most likely wrong.  The definition field for every attribute should precisely define the concept.  See ISO/IEC 11179-4 and ISO 704 for more details.   (ITS)  

5.    How do you treat one document with 2 different designations (e.g. ISO 177799:2000 / BSI 7799-1:1999)   (Standards Metadata Registry Committee)

c.        Title : No comments  

d.       Description  

1.    See below for my suggestions about the current Identifier element. Also, see Related Resources where alternative standards that are essentially the same will be referenced.  

This element should be the one unique identifier for all standards.   (Linda Hill)  

2.    Change name to Identifier and specify that this is “An unambiguous identifier for the standard, including SDO identification.” Give an example. Assume that only on e identifier will be given.  

Make the element Mandatory.   (Linda Hill)  

3.    The attribute “Description” is very imprecise. What should a user expect to retrieve from this field?   (Frank Farance)  

e.        Identifier       

1.    Should the identifier be a  two part field - one for the number, and one to indicate which number (e.g. ISBN, etc.)?  (Stephen P. Oksala)  

2.    This element assumes a “formal identification system” for standards, which I believe does not exist and which would require a separate standards effort to put in place. Is this necessary?  An alternative would be to adopt an existing identification standard from the one that you list (DOI or ISBN).  But this would add a registration burden to the standards process – obtaining and assigning the identification numbers to each published standard.  My recommendation here assumes that the SDO’s need and will adopt such an external identification system and that it will use it along with their own standards number, which will be recorded in the Identification element.  

Change name to the identification scheme that will be used.  For example, “ISBN” or “DOI” or … That is, make the element name specific to the standard.  

If more than one such standard’s numbering scheme will be used, then some other solution will be needed:  could be multiple elements -– one for each scheme – or this element could be named something like Universal Identifier with two elements (or use XML attribute):  Scheme + ID.  So, if a standard actually has an ISBN + a specific standard’s ID, the entry would br like:  

--   Scheme:  ISBN
--   ID:   1234-5566  

--   Scheme:   SDO
--   ID:   00-45-1956          (Linda Hill)  

3.     “Recommended best practice” is to use a formal identification system, several examples of which are listed.  This standard should either specify a particular formal identification system, or specify a mechanism for identifying the system that is used in any particular case.    (Charles Roswell)  

4.     ISO 19115 provides an element that provides for the type or system of the identifier, in line with Charles Roswell’s comment.  It also allows for more than one identifier.  The definition is “an unambiguous reference standard in a given context” but a document may have an identifier that is unique to its context, but varies with context, but varies with context, for example, the same book will have different call numbers in the Dewey Decimal and Library of Congress cataloguing systems.  More than one identifier, with the identifier system provided in each case, should be possible.   (Barry, INCITS)  

5.     What does “unambiguous” really mean?  In the attribute “Identifier”, a URL may point to different items over time. Is this unambiguous?  Also, how does one know how to de-reference a URL (Does it point to a page or a file)?    (Dan Gillman and Frank Farance)  

6.     [ … A] piece of metadata called the "document identifier".  It is discussed in this section: http://www.oasis-open.org/spectools/docs/wd-spectools-instructions-01.html#s.metadata.  A scheme is proposed for assigning document identifiers (which are intended to be used as the root of a filename, with the extension reflecting the format used in the file).  The SAML TC and the UBL Naming and Design Rules subcommittee have been trying to apply this scheme as best they can, but experience has shown that it needs some tweaking. I'm hoping you all can help in this endeavor.  

I'd like to propose the following scheme instead, and suggest that we conduct an email discussion on this topic until December 2.  At that time, I'll summarize and try to propose a revision of the specification template instructions.

--For contributions and proposals that are outputs of one or more individuals /organizations but are not an output of the TC in question:
                        p-{name_of_proposer}-{description}-nn
                                    Where:
                                              name_of_proposer
                                              Is typically the last name of the main individual making the proposal.                                                                                    description 
                                              Is some descriptive text, possibly with embedded hyphens, that identifies the proposal.  

                                                                        Nn
                                                                                  Is a monotonically increasing number starting from 00 representing the revision of the document.  

--For outputs of a TC:  

                                                            {type}-{name_of_TC}-{description}-nn
                                                                      Where:
                                                                                           type
                                                                                                    wp=white paper
                                                                                                    wd=working draft (may not have reached consensus, is in progress)                                                                                                                        cs=committee spec (has had 2/3 positive vote)  

This list is not closed, but new type keywords should be added only advisedly, and hopefully only after consultation with the chairs list.  

                                                name_of_TC

Is some canonical shorthand for the TC name, or possibly one of its subcommittees (though this may make the name too long).

                                     --For OASIS Standards:

                                                        {name_of_TC}-{description}-Vnn                                               
                                                                Where:                                               
                                                                        Vnn
                                                                        Is a representation of the version of the Standard, however the TC wants to reflect that.  

                                                Examples:  

                                    wp-ubl-codelist-01                                                           
                                                Is the second revision of the UBL TC's Code List white paper.  

                                                            cs-sstc-core-00
                                                            Is the first revision of the Security Services TC's core specification in Committee Specificiation form.  

                                                            sstc-samlcore-v10
                                                            Is the SAML V1.0 core specification in OASIS Standard form. (I've added "saml" to the description because "sstc"                                                                doesn't mean much to some people).  

                                                            p-smith-docbooklinks-17                                                           
                                                            Is the seventeenth revision of Smith's proposal for DocBook linking.  (Eve Maler)

 f.       Name of Standards Developing Organization (SDO)  

1.     Since there is a possibility that more than one SDO is involved, a simple list of elements becomes hopelessly confused without creating such a set of elements. This structure supports the use of a directory (separate database) of specific committees of SDOs, which can be referenced from the metadata record.  

Making the URL element specific permits the designation of the element as containing a network address, which can then be used by services (e.g., hyperlinking). Contact information can be further specified, if desired.  

Create a set of nested elements to describe the SDO. Make this set of elements repeatable (unlimited) for the case where more than one SDO is involved. The set could be:

- SDO (unlimited)
            - Name (once)
            - Acronym (once)
            - Committee (once)
            - URL (once)
            - Contact information (once)        (Linda Hill)  

2.   This call for providing multiple names if more than one SDO is responsible for the standard, but the  maximum occurrence is shown as         "one." The standard needs either to allow multiple entries of SDO names, or to specify how the elements in a single list of names are separated.   (Charles Roswell)  

g.        SDO Committee  

1.     “SDO Committee” should be mandatory, not optional – this info is useful for doing follow up research about the committee and possible other related documents.  (American Welding Society A9 Committee)

h.       SDO Information  

1.   [ … ] the data element called “SDO Information element” could more precisely be named “SDO Contact Information.” Making the SDO Contact Information optional may cause some difficulties.  The custodian of any standards repository will always want to know the developer’s contact information.  In our JSR, we have included the mandatory data element of “submitter,” which requires entering contact information about the submitter of the standard to our Registry.   (ITS)  

2.    ISO 19115, and the FGDC Metadata Standard on which much of it is based specify the contact information in detail This item should specify the specific forms in which the contact information (phone, mail, URL…) is available and specify the required content for each form.   (Barry, INCITS)  

i.        Subject  

1.     Making the “Subject” element optional may cause serious difficulties both for the custodian of any standards repository and for the users of the repository who will often want to search the repository by subject.   (ITS)  

2.     Create a set of nested elements, or use an XML attribute, so that the source scheme of the term or classification can be identified.  For example:

- Subject (unlimited)
            - Scheme (once)
            - Term-Notation (unlimited)          (Linda Hill)  

3.     The description states "Need provision to cite both scheme used and the specific classification identifier." That provision needs to be specified.   (Charles Roswell)  

4.     If this standard is going to suggest that a "best practice" is to use a controlled vocabulary or formal classification scheme, I recommend that such a vocabulary or scheme be developed and published as part of this standard so that users will have a "default" thesaurus or scheme that they can use and cite in creating the record. Since this is an optional character string field, it seems that users would be able to cite multiple thesauri or schema in this field.   (Bruce Wescott)  

j.         Current Status  

1.     In "current status" there can be a pretty big gap between "project initiation" and "draft available".  In our case, we have a project approval which could be the project initiation, but it is also the first approval. This might lead to some confusion over what date to put in when. […]Also in status - there is the final approval by the SDO, but then there is an additional approval of the document as an ANS.  This would come after published I would guess.  (In these days of electronic standards, I would think that the distinction between approved and published would be pretty small.)  Also - considering point (1) above, there could also be "approvals" from international organizations.  (Stephen P. Oksala)  

2.     “Stage of the document” - ISO has standard codes for this – see http://www.iso.ch/iso/en/widepages/stagetable.html#60.  Should these be used/required?  The words “international standard” would have to be changed to fit individual organizations.   Disadvantage is that the numerical code alone is not very helpful if you don’t have them memorized.  (American Welding Society A9 Committee)  

3.     “. . . in the ‘Current Status’ row, will the stages also include the equivalent names, for example, those of the ISO documents.”   (Lionel Difford)  

4.     Do you need other stages, such as “superseded” or “out of print”.  Add a date element or attribute to define “current” – that is, current as of such-and-such date – because metadata does not always keep up with reality.  For example:

- Current status
            - As of (date) (once)
            - Status (once)

Make the five stages a specified set of domain values for the element. That is, values for this element must be one of the specified values representing stages of development.   (Linda Hill)  

5.     I can think of several "statuses" other than the five defined. It would be very helpful to have:

-- Pending -- If further action on the standard awaits action on some other development which is a logical predecessor, it would be great to have a pointer to what that other development is.

-- Replaced by -- If activity has been suspended in favor of some other standard, this status should be indicated. If we go this route, it may be advisable to update the field named "Replaces" to be named "Replaces/Replaced by" and update its definition so that the field can "point" to either the predecessor or the successor.   (Bruce Wescott)  

6.     The "Current Status" element proposed doesn't appear to map nicely onto the processes of some other standards developing organizations. Specifically, this model doesn't seem to fit the IETF's processes (see http://www.ietf.org/rfc/rfc2026.txt) very well.   (Randy Presuhn)  

7.     The attribute "Current Status" is not harmonized with ISO stage codes.   (Frank Farance)  

k.       Date of Most Recent Action  

1. Not needed as a separate element if the date element is added to the Current status as recommended above.   (Linda Hill)  

l.        Referenced Standards  

1.   Is a simple narrative statement sufficient? Should this, instead, be a set of bibliographic elements describing title, organization, date, etc.?   (Linda Hill)  

2.   A standard can contain both normative references and a bibliography of documents that it refers to. There ought to be an optional element that contains these documents that appear as nonnormative references in the standard. This element is not the same as Related Resources, because the Resources element can include elements that the standard does not refer to. The two cases ought to be distinguished. Also, the name of Referenced Standards should be changed to Normative references, to distinguish the other standards that are an implicit part of the standard from those the standard refers to but does not incorporate.   (Barry, INCITS)  

m.       Replaces  

1.     “Replaces” field – would  requiring the use of the Designation parameter in this field  help consistency?  (American Welding Society A9 Committee)  

2.     WG11 has reviewed the fields and elements comprising the “Standards Metadata Element Set, v.3.0” and would like to point out that element information identifying amendments of standards and their relationships seems to be missing from the list.    (ISO/IEC/JTC1/SC29/WG11 N5137)  

3.     Clearly setting out the ID of the replaced standard permits hyperlinking to the metadata for the standard, if available in the system.  [Recommendation:]  Create a set of elements to describe the replaced standard(s), such as:

Replaces (unlimited)
                    - Identification (once)
                    - Title (once)                                  (Linda Hill)  

n.        Related Resources  

1.     Same comments as for Referenced standards above. Actually, all these three elements: referenced standards, replaces, and related resources are relationships between this standard and other resources and they could all be structured the same – in fact, they could represented as types of relationships. For example, Relationship - Type (e.g., replaces, normative reference, …) Caution should be used in creating a system where someone has to maintain the metadata of a standard by keeping track of subsequent endorsements, adoptions, etc.   (Linda Hill)  

o.       Format  

1.     Why make “format” optional?  For drafts that aren’t yet in final format?  If this is the case the description of this field could add the note that if drafts are not yet in final form this field shows the intended format to be used when the document is “published”.  (American Welding Society A9 Committee)  

2.     If multiple characteristics of format need to be represented (e.g., size of file, special software/hardware requirements), then a set of elements is required. If MIME type alone is sufficient (augmented with terms for non-digital formats), then a single element will suffice. If there is a particular Registry of Mime types that is officially recognized for this purpose, it should be identified.   (Linda Hill)  

3.     "Recommended best practice" is to select a value from a controlled vocabulary. The standard needs to specify a mechanism for identifying the controlled vocabulary used in a particular instance.   (Charles Roswell)  

p.       Language  

1.     Language – where more than one is specified, is there a need to specify a standard delimiter in the string field?  How can this be optional?  If a standard is in German, I can’t read it!   (American Welding Society A9 Committee)  

2.     Why confuse things by accepting both 2 and 3 character codes?  It should be stated that if there are other language versions of the standard, they will be cited as.  Specify either 2 or 3 character language codes and the associated ISO 639 standard.  Make the element Mandatory.   (Linda Hill)  

3.     The reference to RFC3066 needs to specify the publisher of RFC 3066.   (Charles Roswell)  

4.     Why is RFC 3066 only recommended, rather than required? If language can be specified under more than one system, then both the language code and the system under which the code is defined must be provided, as for other identifiers. One possibility is to make RFC 3066 the default; if no system is specified, RFC 3066 is assumed.   (Barry, INCITS)  

5.   How do you treat multi-lingual standards vs. separate language versions?    (Standards Metadata Registry Committee)

q.        Rights Management           

1.     The fields of “Datatype” and “Obligation” were omitted under the “Rights Management” element.  Perhaps the correct entry in the “Datatype” field would be “Character String” and for the “Obligation” field would be “Mandatory” (because copyright protection can be invoked only if the viewer sees that the document entered into the repository is copyrighted and he/she honors that copyright).  (ITS)  

2.     We note that there is no dataa in the Rights Management filed.  This needs further thought since there are two distinct kinds - rights management in the document itself, and rights management associated with the content of the standard. (Stephen P. Oksala)  

3.    Needs a set of elements adopted from other standards.   (Linda Hill)  

4.     Again ISO 19115 and the FGDC metadata standards provide guides as to how to specify the content in more detail. The different kind of rights and possible limitations under each should be listed. Guidance can be obtained from the FGDC metadata standard and ISO 19115.   (Barry, INCITS)

Participants:  

ISO/IEC/JTC1/SC29/WG11 N5137  

Barry, INCITS (International Committee for Information Technology Standards)  

Lionel Difford, INCITS K5 committee  

Frank Farance, INCITS (International Committee for Information Technology Standards)  

Dan Gillman, INCITS (International Committee for Information Technology Standards)  

Joanna Goodwin, ISO  

Evie Gray, U.S. Dept. of Commerce, NTIA/ITS.P, on behalf of Kathy Higgins, NIST/OLES  

Bill Ham, INCITS (International Committee for Information Technology Standards)  

Linda Hill, INCITS (International Committee for Information Technology Standards)  

Eve Maler, Sun Microsystems  

Stephen P. Oksala, Vice President, Standards Society of Cable Telecommunications Engineers  

Randy Presuhn, INCITS (International Committee for Information Technology Standards)  

Bill Rippey, NIST, Chairman of AWS (American Welding Society) A9 Committee  and Joel Milano, Senior Systems Engineer, NAVSEA/Carderock, Advisor to AWS (American Welding Society) A9 Committee  

Charles Roswell, INCITS (International Committee for Information Technology Standards)  

Andy Schoka, INCITS (International Committee for Information Technology Standards)  

Standards Metadata Registry Committee

Bernard Vatant, Consultant – Mondeca, Chair - OASIS TM PubSubj Technical Committee  

Bruce Wescott, INCITS (International Committee for Information Technology Standards)  

Appendix  

AWS Standards Information Examples
Encoded According to Standards Metadata Element Set, v3.0
Editor, Bill Rippey, Chairman, A9 Committee of the American Welding Society
Dec. 20, 2002